Heise 16.02.2026
07:30 Uhr

heise+ | Kubernetes: Der Weg von der Ingress API zur Gateway API


Mit der Gateway-API gibt es einen Nachfolger der Ingress-API, der diese sowohl bei Funktionstiefe, Komplexität und Enterprise-Tauglichkeit übertrifft.

heise+ | Kubernetes: Der Weg von der Ingress API zur Gateway API

Im November 2025 sorgte die Nachricht vom Ende des Community-NGINX-Ingress-Controllers für Unruhe innerhalb der Kubernetes-Community. Schnell machte die Einschätzung die Runde, das Ende des Controllers bedeute auch das Ende der Ingress API selbst und erfordere innerhalb weniger Monate den Umstieg auf die im Post erwähnte Kubernetes Gateway API. Nachdem sich der aufgewirbelte Staub gelegt hat, ist es Zeit, sich die Fakten anzusehen und sich der Gateway API als Nachfolgerin der Ingress API zu widmen.

Das angebliche Ende der Ingress API war eine Fehleinschätzung, hier wurde sprichwörtlich das Kind mit dem Bade ausgeschüttet. Der Community-NGINX-Ingress-Controller ist lediglich eine von vielen Implementierungen der stabilen und eben nicht abgekündigten Ingress API. Damit lässt er sich ohne Funktionsverlust durch jeden anderen Ingress-Controller ersetzen, ohne die Ingress API aufzugeben. Letztere ist sehr einfach aufgebaut. Oft benötigte Funktionen sind nicht Teil der Ingress API, werden aber durch Ingress-Controller bereitgestellt. Der Zugriff auf diese Funktionen erfolgt an der Ingress API vorbei.

In Kubernetes hat sich historisch ein Pattern etabliert, controllerspezifische Konfigurationen in den Annotationen des entsprechenden Kubernetes-Objekts abzulegen. Die Konvention für Annotation Keys ist: <Controller-Domain>/<Konfigurationsoption>, also beispielsweise: